home *** CD-ROM | disk | FTP | other *** search
- Path: ifi.uio.no!usenet
- From: ludvigp@ifi.uio.no (Ludvig Pedersen)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: doubling pixels horizontally
- Date: 12 Mar 1996 14:52:21 GMT
- Organization: Dept. of Informatics, University of Oslo, Norway
- Message-ID: <3072.6644T1140T2815@ifi.uio.no>
- References: <4f4ibc$gl9@news.cs.tu-berlin.de> <591.6610T1165T2102@login.eunet.no><1045.6611T753T2256@vip.cybercity.dk><4faoe1$47@sunsystem5.informatik.tu-muenchen.de><2991.6612T1034T625@vip.cybercity.dk><576.6613T1070T1730@login.eunet.no><1257.6614T57T922@vip.cybercity.dk>
- <5257.6639T1152T2935@ifi.uio.no> <4i00nt$r3g@sunsystem5.informatik.tu-muenchen.de>
- NNTP-Posting-Host: gymir.ifi.uio.no
- X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
-
- >huh ? this would equal "movem load 12 regs slower than normal load".
- >on 020, movem load is quicker using lot regs. for example I got 9.7 cyc
- >movem load from chip instead of the usual 12 cyc.
- >And in fastmem 4.9 movem load vs. 6.4 normal load.
- >so anyone of us got a bug or 030 is very different here ?
-
- Its not a bug, bustest also confirmed that. Reading from fastram, move.l is
- faster than movem. But on writing movem is faster! :-)
-
- >Do those "free c2p" routines really run 5.6 mb/sec ?
-
- Hehe, no, but you usually don't play Doom without any bitmap-DMA, do you! ;)
-
- I wrote "ALL DMA IS OFF!" remember? (It was even uppercase letters)
-
- If you turn on 256 colors you get a slow-down.
-
- >: >imho this should do 7mb/sec in the store part. if the movem
- >: >is very fast, you aproximate the 7mb/sec also doing copying.
- >: 7 Mb/s is not possible. Remember that you have to access the same data-bus
- >: to read from FastRam.
- >I said "very fast cpu" and "aproxiamte 7mb/sec" :)
-
- You should have said something like a fast cpu with 1+ MB internal cache! ;)
- But that would be cheating! :-)
-
- >: >|> register move: 40.6ns
- >: >huh ? a register move is 2 cycles. you got 24.63 MHz ?
- >: Ehh..No, I have 50 mhz.
- >: I tested it myself. (just to be sure)
- >: I was able to do 24400000 register move's and 203300 dbra's per second.
- >2.04 cycles for the reg move.
- >if the dbra number misses 2 zeros, it's 2.45 cycles/dbra (wow!), if
- >the "203300" is true, it's 245 cycles (laaaame!) ;)
-
- What is LAME? >:( That you have problems with you math again? :-)
-
- >: A dbra is 3 times slower than a register move so that's 25.0 peek MIPS.
- >uhm... yep, 6 cycles dbra on 020, too. exactly enough for the 6 free cycles
- >of a chipmem store.
- >so on your card rather 8333333 dbra's /sec ;)
- >: 1.000.000.000 ns / 25.009.900 = 39.98 ns
- >what ?
-
- What you forget is that a move uses 2 clock cyles.
-
- ONE clock cycles is 20 ns. So TWO clock cycles must be 40 ns.
-
- How *hard* can it really be??? This is pretty elementary math! ;-)
-
-
- >: We support both 2xN sprite-dithering (1 pass) and normal 2xN (2 pass).
- >: If your render-routine is 25 fps or slower using the 2 pass version
- >: doesnt matter at all in speed and framerate. You only get a better-looking
- >: display.
- >yep. no need for ghost-look doing doom, descent etc.
- >just intuiscreen, supporting all monitors, or genlock or whatever :)
-
- That would be great! :)
-
- >: Can you explain about that monitor side-effects stuff you are talking
- >: about. Is this something new?
- >my 1084 shows 2x2 ghost screens well, same goes for my TV over both
- >SCART and composite video.
- >my friends tv would show some color stripes, i.e. disturbed display.
- >(could still play xtreme racing :)
- >i.e 1084 -> most users no problemo. ghost-look looks even better
- >over composite video vs. rgb-port, because of smear (hardware-dither ;)
-
- Dithering looks ok on a multisync too. (Atleast in PAL) But you don't get any
- smear! ;) "Lace"ing the dither is the way to go in both cases.
-
-
-
- <sb>Ludde - Amiga Demo Coder
- <sb>Virtual Reality & Official Be developer
- <sb>ludvigp@ifi.uio.no
-
-